This invention relates to digital communications, and more particularly to various methods and arrangements associated with a novel clock slaving algorithm.
Clock slaving is a process by which two clocks are significantly synchronized by having one of the clocks adjust to match the other clock. What makes clock slaving difficult, at times, is that there will always exist an inherent difference between the two clocks, even though they may be specified to run at the same rate. In other words, for all practical purposes, no two clocks are the same. The differences may be the result of manufacturing imperfections, material disparity, temperature, etc. For example, two ordinary wall clocks will never run exactly at the same rate, even though both are specified to increase at the same rate (60 seconds, 60 minutes, 24 hours, etc . . . ). Over time, they will first differ by seconds, then minutes, then hours, etc.
Timing is one of the critical issues confronting the digital media movement. Packetized digital information needs to be played back (processed and displayed) at specific intervals. If these intervals are even slightly off the viewers will probably notice.
Thus, careful attention is paid to timing. Take for instance the transmission of MPEG-2 video. Here, this digital media is ordinarily transmitted with presentation timestamps (PTS) that indicate when the data should be rendered. These timestamps are generated as values sampled from a reference clock that runs at a specified rate (27 MHz in the case of MPEG-2). When the data is broadcast to a remote client that does not have direct access to the reference clock used to generate the PTSs, a host clock (at the receiving client) must be used as reference to determine when a PTS becomes valid, i.e. is now. However, because these are two different clocks, a disparity will exist and grow over time between the PTS and the host clock samples they are compared against. An eventual buffer overflow/underflow will occur as the PTSs values change at a subtly different but diverging rate from the host clock.
Because of this problem, MPEG-2 systems streams contain reference clock values known as Program Clock Reference (PCR), which are transmitted at regular intervals. A remote client receives those sampled values and is able to determine the drift that exists between its clock (host clock) and the reference clock, and make small adjustments to match it exactly. This process is one form of xe2x80x9cclock slavingxe2x80x9d that, in the past, has been provided via a phase locked loop (PLL) circuit, whereby a Voltage Controlled Oscillator (VCO) is adjusted to output a 27 MHz signal that is slaved to the reference clock. In this case the VCO acts as the host clock.
One of the problems with this solution is that each separate data stream will require access to a PLL. Thus, if two or more streams are to be watched simultaneously, then two or more PLL arrangements are required.
Moreover, as personal computers are increasingly used in the broadcast realm, they will encounter this problem. It is not usually feasible to have a VCO that is readily accessible by a user-mode process, and thus an alternative solution must exist.
Furthermore, because a PC is a versatile platform, there can be more than one process at a single time being used for broadcast, in which case each would need to slave to its own broadcast""s reference clock. Again, were they all to use the usual PLL arrangement, an equal number of on-host VCOs would need to be available.
Consequently, there is a need for improved methods and arrangements that can be used to provide the requisite clock slaving without requiring extensive and potentially costly hardware. Preferably, the methods and arrangements will be suitable for use with any type of digital signal/media and adaptable to a variety of devices and systems.
In accordance with certain aspects of the present invention, an algorithm is provided that can be used to detect and track the difference between an on-host clock (subsequently referred to as xe2x80x9chost clockxe2x80x9d) and a remote clock (subsequently referred to as xe2x80x9creference clockxe2x80x9d). As part of the algorithm, a scaling value is is computed and tracked over time. The scaling value, when applied to the host clock, results in clock values that increase at substantially the same rate as the reference clock itself increases. Hence, the host clock will have been slaved to the reference clock.
The exemplary algorithm described herein does not rely as heavily on hardware as previous solutions (i.e., PLL solutions, etc.). Instead a high-resolution host clock is sampled and the disparity between it and the reference clock is tracked. The disparity results in the scaling value. When a host-clock delta value is multiplied by the scaling value to obtain a scaled delta value, the scaled delta value will equal to the reference clock delta value. As such, over time, the scaled delta value will change at a rate that is substantially equal, and thus slaved, to the reference clock delta.
The algorithm described herein can be used to slave a host clock to any reference clock in any broadcast scenario. While the solution is presented using an MPEG-2 specific solution, the core algorithm is itself generic in nature. Thus it provides a way to slave that is generic to any broadcast situation in which clock-slaving must happen.
This algorithm is particularly useful to computers and other like devices because all processes can use the same multimedia timer, but each will generate a different scaling value to generate a host clock that effectively slaves it to its corresponding reference clock.